home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000388_news@columbia.edu _Tue Sep 24 13:59:10 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA21632 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 24 Sep 1996 13:59:09 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA26418 for kermit.misc@watsun; Tue, 24 Sep 1996 13:59:06 -0400 (EDT)
  4. Path: news.columbia.edu!psinntp!psinntp!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: MS-DOS Kermit wish list
  8. Message-ID: <1996Sep24.095354.85355@cc.usu.edu>
  9. Date: 24 Sep 96 09:53:54 MDT
  10. References: <5266f7$8nv@mirage.skypoint.com>
  11. Organization: Utah State University
  12. Lines: 53
  13.  
  14. In article <5266f7$8nv@mirage.skypoint.com>, escargo@skypoint.com (David S Cargo) writes:
  15. > Here's a wish list of features I wish MS-DOS Kermit had.  These
  16. > are all things that would make life easier for me.  Whether other
  17. > people would need them, I don't know, but here's their chance to
  18. > say.
  19. > 
  20. > 1)  During multifile get and put, I wish there was a way of stopping
  21. > the transfer after the current file is completed.  We have several
  22. > ways of stopping NOW, but none for stopping after the current file
  23. > has been successfully transmitted.
  24.  
  25.     Hmmm, a useful idea. We'll consider that one.
  26.  
  27. > 2)  An easy way of knowing if a terminal session is being recorded.
  28. > After the ^], we can toggle recording, but it's not always clear
  29. > if recording is on or not.  I'd like this on the status line, but
  30. > having it on the screen with the ^] would work too.
  31.  
  32.     The status line is pretty full already. I'll consider the matter,
  33. however. The present technique is quit the file group after the last wanted
  34. file.
  35.  
  36. > 3)  A way of locking the keyboard during transfers.  I use my machine
  37. > for long, unattended transfers.  I also have cats that walk over the
  38. > keyboard.  It would be helpful if there was a way, even a simple one,
  39. > where the keyboard would not react to the Z, E, C, and other keyboard
  40. > commands active during transfers if the keyboard was in a locked state.
  41. > The lock state could be a toggle; probably a control or alt key
  42. > sequence would be best, since the chances of random paw presses getting
  43. > it is small.
  44.  
  45.     I'm afraid this is a problem for the system manager (the cats)
  46. and their worker (you).
  47.  
  48. > 4)  The screen during file transfers currently shows the number of
  49. > retries.  The show statistics screen doesn't really spell out why
  50. > retries were needed.  However many reasons there are for needing a
  51. > retry (nack, timeout, whatever), I'd like to see reflected on the
  52. > statistics screen.  Each cause is generally a different type of
  53. > network problem; I'd like to know what part of the network to focus
  54. > my attention on.
  55.  
  56.     There are many reasons, as you say, but the Kermit protocol
  57. stack is blithely unaware of almost all. The reason is, "doesn't work"
  58. really does mean "doesn't work" and the lower level workers tried
  59. as hard as they could before giving up. Thus the higher layers can
  60. do nothing about the matter other than either retransmit or quit.
  61. There is no cascasding upward of failure details (because there is
  62. no need if a lower level workers have done all they could).
  63.     To solve "networking" problems typically requires other tools.
  64.         Thanks,
  65.     Joe D.
  66.